!buildbot emscripten

🤖 New build scheduled with the buildbot fleet by @hoodmane for commit 0ffb76b 🤖

Results will be shown at:

https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F137470%2Fmerge

The command will test the builders whose names match following regular expression: emscripten

The builders matched are:

• WASM Emscripten PR

!buildbot emscripten

🤖 New build scheduled with the buildbot fleet by @hoodmane for commit 04e0541 🤖

Results will be shown at:

https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F137470%2Fmerge

The command will test the builders whose names match following regular expression: emscripten

The builders matched are:

• WASM Emscripten PR

There's three blockers to this at present:

1. The check-c-globals analyser check that is failing CI on this PR
2. The test suite CI failure that is also visible on main, because of the change from gh-131876: extract _hashlib helpers into a separate directory #136995. gh-131876: extract _hashlib helpers into a separate directory #137319 looks like a possible fix; however, it looks like it's on hold pending some other changes.
3. The refactoring of the build script that we discussed at EuroPython (and on the buildmaster-config PR) to encode the Emscripten version as part of the build script, and use an argument to point at a local cache directory.

The alternative to (3) would be to violate the "RC1 is where we lock in the Emscripten version" rule, and bump to 4.0.12. That isn't an approach we could take in the general case, but given this is the first "back to Tier 3" release, and there's no impact on downstream packagers (since nobody can publish to PyPI, so nobody will be relying on the 4.0.11 ABI guarantee), I could probably be convinced to do this - but I'd like @hugovk to sign off on the plan as release manager.

Of course (3) is going to be needed in the fullness of time - it's just a question of whether we need to do it right now. And (1) and (2) will need a fix regardless.

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

This PR isn't urgent so I think it would be fine to block it on making an Emscripten version manager. But it would also be fine to bump the Emscripten version for 3.14 imo.

I reverted the hashlib refactorization by the way, so failures on main shouldn't be because of this.

Thanks @picnixz. Failure on main is a runtime failure in a test about calendars and locales, not the linker error.

Hmm the C parser doesn't work with out of tree builds because it passes a bunch of invalid paths like -I/home/rchatham/cpython/*./Include cc @ericsnowcurrently
https://github.com/python/cpython/blob/main/Tools/c-analyzer/cpython/_parser.py?plain=1#L120

I can't reproduce the NotImplementedError locally:

NotImplementedError: (Struct(file=FileInfo(filename='/home/runner/work/cpython/cpython/Include/pystate.h', lno=62), name='_stack_chunk', data=[Member(name='previous', vartype=VarType(typequal=None, typespec='struct _stack_chunk', abstract='*'), size=None), Member(name='size', vartype=VarType(typequal=None, typespec='size_t', abstract=''), size=None), Member(name='top', vartype=VarType(typequal=None, typespec='size_t', abstract=''), size=None), Member(name='data', vartype=VarType(typequal=None, typespec='PyObject', abstract='* [1]'), size=None)], parent=None), [TypeDef(file=FileInfo(filename='/home/runner/work/cpython/cpython/Include/pytypedefs.h', lno=18), name='PyObject', data=VarType(typequal=None, typespec='struct _object', abstract=''), parent=None), TypeDef(file=FileInfo(filename='/home/runner/work/cpython/cpython/Python/emscripten_trampoline_inner.c', lno=1), name='PyObject', data=VarType(typequal=None, typespec='void', abstract=''), parent=None)])

I reverted the hashlib refactorization by the way, so failures on main shouldn't be because of this.

My apologies - I missed that the cause of the CI failures on main had changed. Thanks for the revert - now to work out what's going on with Calendars... :-)

The alternative to (3) would be to violate the "RC1 is where we lock in the Emscripten version" rule, and bump to 4.0.12. That isn't an approach we could take in the general case, but given this is the first "back to Tier 3" release, and there's no impact on downstream packagers (since nobody can publish to PyPI, so nobody will be relying on the 4.0.11 ABI guarantee), I could probably be convinced to do this - but I'd like @hugovk to sign off on the plan as release manager.

@freakboy3742 Yes, I think it's okay to bump the Emscripten version given what you say.

@freakboy3742 Yes, I think it's okay to bump the Emscripten version given what you say.

Thanks - I've just updated the buildbot to use 4.0.12.

!buildbot emscripten

🤖 New build scheduled with the buildbot fleet by @freakboy3742 for commit 6fd7bfe 🤖

Results will be shown at:

https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F137470%2Fmerge

The command will test the builders whose names match following regular expression: emscripten

The builders matched are:

• WASM Emscripten PR

@hoodmane The buildbot is now running 4.0.12, but it's definitely not happy. The problem seems to be back in HACL - but I've merged with main, so it's not the same problem as before (and the problem doesn't exist on main right now).

It looks to me like the build failure is due to buggy code in this PR. Which is good news =)